1. Field of Invention
This invention relates to the field of configuration management software for managing development of a software project. More particularly, it relates to a system and method for estimating a creation time for one or more versions of a software project based on input information regarding software component versions included in the one or more versions of the software project and creation times of the software component versions.
2. Discussion of Related Art
Developing software applications and products (which includes both initial development and later modifying or adding to the initial development) often requires the coordinated efforts of many developers (e.g., software programmers). This coordinated effort is referred to herein as a “software development effort” or “development effort,” and a body of work (e.g., one or more software products, including software applications) being developed by the effort is referred to as a “software development project,” “software project,” or “project.” A software development effort may comprise one or more software projects. At any given time, as part of a software development effort, multiple developers may be working on different software components of a software development project and/or different versions of these software components (e.g., for different users or situations). Thus, there may be multiple concurrent software development efforts ongoing, at least some of which use or involve the modification of common software components, including different versions of those software components and sometimes multiple versions of components.
Frequently, a software development project may involve several, or even dozens or more, of developers and managers, and from a few to even hundreds of software components. Managing one or more software development projects and the concurrent development of these different software components and versions is commonly referred to as configuration management (CM). Computers or computer systems running CM software applications (i.e., programs) assist developers and project managers in the complex task of managing a software development project, including maintaining coherency between different software components and versions. (Hereafter, the term “CM application” may be used to refer to such computers or computer systems, or to a CM program for executing on a computer or computer system.)
One popular, conventional way of managing projects of a software development effort is referred to herein as a “label-based system.” Label-based CM applications (i.e., CM applications running in label-based systems) have long been in use in the field of software development, from the Revision Control System (RCS) proposed in 1985 through modern CM applications like Rational ClearCase available from the IBM Corporation of Armonk, N.Y.; Perforce, available from Perforce Software, Inc., of Alameda, Calif.; Concurrent Versions System (CVS), an open-source software project; PVCS available from Serena Software, Inc., of Redwood City, Calif.; and many others.
In a label-based system, information on software components and their versions is stored separately from project information. A developer, working on a project in a label-based system, may edit individual software components of a project (e.g., individual code files) and may create one or more versions of the software components. Information on these software component versions (i.e., the versions of the software components) is stored by the label-based system along with edit/creation times for the versions. This information on software component versions may, in some label-based systems, be stored in a tree/branch format describing a relationship between versions of the software components and versions of a software project.
A developer may store additional information (e.g., metadata) in the records of the label-based system describing the software components and/or software component versions which are to be included in a “build” or “release” of a software project, which is a version of a software project at a particular time. (Herein, where the term “release” is used, it should be understood to refer to both a “build” and a “release,” and therefore does not require any distribution to inside or outside parties.) For example, if a developer, working on a “Version 2.0” of a software product, creates new versions of some software components while fixing bugs of and/or adding functionality to the “Version 1.0” of the software product, the developer may store as a part of the additional information an indication that the new versions of the software components are to be included in the “Version 2.0” release of the software product. Label-based systems typically only store a single copy of this additional information; that is, if a change is made to the additional information, any information predating the change is lost.
The additional information stored by the developer to describe a release may be used by the label-based system when a release is created to retrieve the appropriate software component versions to be included in the release, and may additionally be used to create a listing of software component versions which were included in the release. This listing may comprise the “label” of the label-based system as a field identifying the release. Once created, this listing may be perpetually stored by the label-based CM application as an indicator of the contents of the particular build of the contents of the particular release of the version of the software project, and may be stored in many ways, for example, as a table in a database. For example, the listing may comprise information such as an identifier for each software component included in the release, an identifier for the version of the software component, an identifier for the version of the software component, and a label for the release (e.g., “RELEASE1” or “TestBuild”). A user of a label-based system, as mentioned above, may then refer to the listing later to determine the state of a version of the software project at a time of the release (i.e., which software components and versions were included in the project).
Table I shows one example of such a listing of software components included in a release named RELEASE1.
TABLE ISoftwareComponentVersionLabelfoo.c1RELEASE1bar.c1RELEASE1
Table II shows a second example of such a listing, including information regarding two different releases.
TABLE IISoftwareComponentVersionLabelfoo.c1RELEASE1foo.c2RELEASE2bar.c1RELEASE1bar.c2RELEASE2other.c3RELEASE2
New systems have been proposed which move away from the label-based system model used by RCS, ClearCase, and others. One such new system is referred to herein as a “time-based system.” An example of such a time-based system is AccuRev 4.5 available from AccuRev, Inc., of Lexington, Mass. Time-based systems are described in greater detail below, and more information is available in the disclosures of U.S. patent application Ser. Nos. 10/894,697 and 10/894,964, both by Damon B. Poole and both of which are incorporated herein by reference in their entireties. It should be appreciated that terminology explicitly employed herein that also may appear in either of the disclosures incorporated by reference should be accorded a meaning most consistent with the particular concepts disclosed herein.
In a time-based system such as AccuRev, information on versions of software projects may be maintained, indicating the software component versions that each version of the project comprises. Some systems may additionally store information on the parent or child versions with which the project versions share a relationship and a history of changes that have been made to the versions (e.g., software component versions which have been previously included in the version of the software project, but are not now, and the time the change was made). This history may be based on a time changes were made and/or a sequence of the transactions/operations that effected the changes. The information on the versions of the software projects may be stored in these time-based systems in many different ways, including as streams.
A “stream” is a data structure containing information describing a version of a software project (or other type of software entity) and a set of software components (i.e., one or more software components) associated with the version. A stream may relate a set of software components to one another and to metadata describing the version of the software development project and/or the software components. The metadata of a stream may be any suitable information about the software components and/or project, such as a status of the software components and/or a status of the project. It should be appreciated that different versions of a software project (or other type of software entity) may have the same content (e.g., may include a same set of software component versions) or different content.
The contents of a version of a software project (i.e., the software component versions of a version of a software project) in a time-based system may be determined in one or more ways. In some time-based systems, contents of a version are determined based on the version hierarchy in which the version is and inheritance properties of the hierarchy. For example, a child version may be considered to have all the contents of a parent version, but a parent version may not have all contents of a child version. Additionally or alternatively, a version's contents may be determined by include and/or exclude rules, stipulating which software components and/or software component versions are included in the software project version and/or which are excluded from the software project version. For example, an include rule may stipulate that all files of a particular directory in a software component file structure be included, and an exclude rule may stipulate that none of the files of subdirectories of that particular directory be included. In some time-based systems, a combination of inheritance and include/exclude rules may be implemented. Information on the contents of a version may be stored by the time-based system as a part of the information on the versions of the software projects (e.g., as the metadata of a stream).
The information on versions of software projects stored by a time-based system may provide developers the ability to determine a status of the version of the software project at various points in time. For example, by examining a history of changes made to the version, a developer may be able to determine contents of the version at a desired time. Additionally, in some systems, a developer may be able to create in the time-based system a record relating to the version that contains the contents of the version of the software project at a particular time, such as when a release is created. Such a record may be stored as a time-based version, including as a “snapshot,” which may be an unchangeable time-based version (i.e., no changes may be made to it in the future). The time-based version may then be easily consulted later to determine the contents of the version at the time (e.g., the contents of the release), rather than examining a history of changes to the version and identifying a particular time and the contents at that time.
Time-based systems offer many advantages over label-based systems. First, while in label-based systems only the current state of a version (e.g., the current contents of the version) is maintained, in a time-based system a history of changes made to the version may permit developers to have more information about exactly what happened to a version at what time, and how the version has evolved over time. This information may help developers in troubleshooting problems, such as by aiding in identifying what changes were made to a version and when the changes were made. Additionally, by storing at all times the contents of a version of a software project, and maintaining a history of changes that may be reviewed later and/or a snapshot identifying a state of a version at a particular time, time-based systems avoid the necessity of creating a separate listing at release time indicating the contents of the release. While in small software projects the step of creating this separate listing may be trivial, in larger software projects of thousands of files this process can take hours and is a waste of system resources.
Applicant has appreciated that, given these advantages and others, developers using conventional, label-based systems may desire to migrate to a time-based system or to permit part of their development teams to perform time-based management of the software development process while integrating with other parts of the team using a label-based process. Applicant has further appreciated the desirability of a migration process permitting a transfer of historical software project information from the label-based system to the time-based systems, such that developers may still access previously-created data in the new time-based system.